Style Guides am Beispiel der Java Look and Feel Design Guidelines von Sun Microsystems - eine kritische Betrachtung

Die „Java Look and Feel Design Guidelines“ von Sun Microsystems liefern Vorgaben für die Entwicklung von graphischen Benutzungsschnittstellen, die auf der Basis der Java Foundation Classes entstehen. Mit diesen Werk versucht Sun eine Lücke zu schließen, die durch die Verbreitung von Java und dem Fehlen einer Richtlinie vom Erfinder dieser plattformübergreifenden Sprache entstanden war. Dieser Beitrag betrachtet die im Style Guide dargelegten Anforderungen an das User Interface von Java-Applikationen und gibt einige kritische Anmerkungen. 1 Aufgaben und Gültigkeit von Style Guides Style Guides (Richtlinien) für das User Interface sind durch die Formulierung von Anforderungen an ein Produkt, eine Produktkategorie bzw. dessen Komponenten ein wichtiges Instrument der konstruktiven Qualitätssicherung, das sich auch für analytische Techniken einsetzen läßt, z.B. statische Prüfungen durch Checklisten [12]. Style Guides für spezielle Produkte entstehen i.d.R. nicht durch ein Normungsbzw. Standardisierungsverfahren, sondern durch privatwirtschaftliche Vereinigungen, z.B. der Motif Style Guide (The Open Group) [16], oder Einzelunternehmen, z.B. Microsoft’s Windows Interface Guidelines for Software Design [10]. Motivation für die Schaffung von Style Guides ist oftmals die starke Marktdurchdringung des Produktes. Während Normen eine hohen Grad an Allgemeingültigkeit aufweisen, dem Nutzen der Allgemeinheit dienen sowie unabhängig von einem Produkt sein wollen, vermitteln Style Guides eher produktspezifische Vorgaben. Der Aspekt der Vereinheitlichung kommt in jedem Fall zu Tragen, wobei Normen für die Qualität von Software-Systemen mit der Schwierigkeit umgehen müssen, daß es „nur wenig allgemein akzeptierte Verfahren zur Bestimmung von Softwarequalität gibt“[9]. Auch müssen Normenwerke häufig erst interpretiert bzw. operationalisiert werden, damit sie in der Praxis zum Tragen kommen. Zur Problematik der Umsetzbarkeit kommt die Vielzahl an Normen wie z.B. die ISO 9241-10 [5], die ergonomische Anforderungen aufführt, die ISO 9126 [6] mit ihren allgemeinen Qualitätsmerkmalen oder die ISO 12119 [7], welche Qualitätsanforderungen und Prüfbestimmungen vorgibt. 1 Die DIN 820 definiert Normung wie folgt: "Normung ist die planmäßige, durch die interessierten Kreise gemeinschaftlich durchgeführte Vereinheitlichung von materiellen und immateriellen Gegenständen zum Nutzen der Allgemeinheit." [8] 2 Der ISO/IEC Guide 2 definiert den Begriff „standard“ „as a document, established by consensus and approved by a recognized body, that provides, for common and repeated use, rules, guidelines or characteristics for activities or their results, aimed at the achievement of the optimum degree of order in a given context.“ [4] 3 Es ist hierbei zu beachten, daß sich die Begriffe „Norm“, „Standard“ und „Richtlinie“ terminologisch nicht klar abgrenzen lassen, da beispielsweise in einigen Normenwerken auch von „guidelines“ gesprochen wird. 4 Ein Beispiel sei mit der ISO 9241-10 gegeben: „ ... these principles can be applied, but as general guidelines only. The manner in which each dialogue principle can be applied will depend on the characteristics of the intended user of the system, the tasks, the environment and the specific dialogue technique used.“ 5 Besonders die Verwendung der Terminologie im Themenbereich „Software-Qualität“ ist bei vielen Normen noch unbefriedigend, so spricht z.B. die ISO 9141 von „requirements“, während es bei der ISO 9126 um „characteristics geht. Diese Kritik ist auch bei den prozeßorientierten Normen und Standards angebracht [13]. Den existierenden produktorientierten Style Guides ist gemein, daß sie nicht oder nur kurz auf die Grundprinzipien der Software-Ergonomie und des Software-Entwurfes verweisen und entsprechende Literatur sowie Normen nennen. Gefordert werden z.B. häufig die Verwendung von Metaphern, die Konsistenz bei den Interaktionsmechanismen und die Bereitstellung von kontextspezifischen Hilfetexten. Der Schwerpunkt liegt jedoch eindeutig bei der Beschreibung der Interaktionselemente eines User Interface und deren Verhalten beim Eintreten von Interaktionen sowie der Formulierung von Vorgaben bei der Gestaltung des User Interface. Durch ihre Produktnähe zeigt sich der praktische Nutzen solcher Richtlinien bei der Entwicklung recht schnell und unmittelbar. Die Ansprüche an wissenschaftliche Literatur wollen diese Werke i.d.R. nicht erfüllen und sind daher als praxisnahe Leitfäden zu verstehen. Ein Ineinandergreifen von Normen und Produktrichtlinien, die es dem Anwender ermöglicht, z.B. die Prinzipien der Software-Ergonomie zu verstehen und diese nachvollziehbar mit einem Style Guide anzuwenden, ist nicht zu beobachten. Auch die wissenschaftliche Literatur kann dieses Defizit nur teilweise beheben, obwohl es positive Beispiele gibt, z.B. im Bereich „ergonomische Evaluierung“ mit dem ERGOguide von Dzida et. al. [2]. 2 Struktur und Inhalt der „Java Look and Feel Design Guidelines“ 2.1 Überblick Das Werk ist sowohl frei im Internet als auch in Buchform [15] erhältlich. Es umfaßt ca. 230 Seiten und drei unterteilt sich in drei Teile: Teil 1 erklärt das Java Look & Feel (L&F) und führt in die JFC ein, während sich Teil 2 Entwurfsentscheidungen für JavaAnwendungen, allgemeinen bzw. grundlegenden Themen der visuellen Gestaltung und dem Verhalten von Interaktionselementen widmet. Teil 3 schließlich legt in 6 Kapiteln ausführlich die Komponenten der JFC dar und stellt Anforderungen an deren Gestaltung und Einsatz. Ein Glossar und ein Anhang über die Handhabung des UI mit der Tastatur ergänzen die Richtlinie. 2.2 Inhalt der Richtlinie und kritische Anmerkungen